The FOUNDATION Fieldbus Specifications are an open set of specifications that define a communications and process control standard for process control system networking which includes field devices. Those specifications (FF-103, FF-131, FF-581, FF-801, FF-816, FF-821, FF-822, FF-870, FF-875, FF-880, FF-890, FF-891, FF-892, FF-893, FF-894, FF-900, FF-940) include protocols for communicating between elements (hosts, field devices, monitors, bridges, etc.) on that industrial network. The configuration parameters for field devices are often prepared prior to the availability of the field device by storing them in a database related to a configuration tool.
At some later time, after the field device is installed, the set of parameters may be written to the field device as part of a “load” operation. Subsequently, an individual device parameter may be changed individually by a user, or the field device may be entirely re-loaded from the configuration database or from a saved image of the device database. However, when writing a new value of a parameter to a field device, the protocol does not include an indication of who or what is writing, or why that value is being written. It could be that a host or supervising element is writing a parameter to the field device as an agent for a human user (such as, an operator, technician, or control engineer). Alternatively, a parameter could be written as part of a series of parameter write messages used to load the field device as part of a larger field device “load” operation performed by a computer-based supervising element, the operation usually being initiated by a user.
Since there is no such indication, current field devices do not distinguish between an operator write and a programmatic loading of the field device, so error checks are the same for each operation. As a result, the load operation often results in a list of meaningless nuisance error indications that are intended to be advisory for a user making one entry at a time. A typical error indication results from writing a first parameter that is not actually being used because a second parameter has selected a configuration option that does not need it. The load of the parameter is harmless, but a warning response and possibly a rejection error response by the field device is unwanted and a nuisance in the case of the “load” operation. In fact, the second parameter may be changed to a configuration value that will utilize the first parameter a few messages later, so the error response would be meaningless and confusing, because the problem would be one of inappropriate order, not of incorrect value.
Another example would be checks that insure that parameter values are properly ordered. A low-low alarm limit must be less than a low alarm limit which, in turn, must be less than a high alarm limit which, in turn, must be less than a high-high alarm limit. While an interactive user must be aware of the ordering restrictions, the provider of the “load” operation generally is not aware of values and their relationship, so any rejections or warning errors from a field device being “loaded” is unwanted and a nuisance.
In general, when in a “load” operation, order and interaction of changing parameter values are usually unimportant rules to enforce. Lengthy lists of insignificant warnings or errors arising from these rules are unwanted and tend to render more significant warnings or errors harder to notice.
There is a need to eliminate or reduce the possibility of generating unwanted or meaningless notifications during an automatic or programmatic “load” operation.